前言
前面十五天,我們處理的大多是「整理與呈現」的問題——怎麼讓 AI 把資料整理成正確格式、正確語氣、不亂編內容。但報告裡有一類任務,性質不太一樣:需要 AI 做一點簡單的分析判斷,例如「本週事件處理效率如何」「有沒有值得留意的模式」。這種任務,光靠前面的技巧還不夠,今天要介紹的 Chain-of-Thought(思維鏈,簡稱 CoT),就是為了讓這類判斷更可靠而生的技術。

一、為什麼「直接要答案」常常不夠可靠
回顧 Day 2 提過的語言模型運作本質:它是在「預測下一個最合理的字」。如果你直接問它一個需要判斷的問題(例如:「這週事件處理得好不好?」),它很可能會跳過中間的分析步驟,直接生成一個聽起來合理的結論——這個結論可能剛好對,但也可能只是「統計上聽起來像對的答案」,而不是真正基於資料邏輯推導出來的。
這跟 Day 11 談的幻覺問題本質相通:當任務需要判斷,而 AI 被允許「跳步驟直接下結論」時,它出錯或臆測的空間就會變大。
二、Chain-of-Thought 的核心概念
Chain-of-Thought 的做法很直接:不要只問「答案是什麼」,而是要求 AI 先把「推理過程」一步一步寫出來,最後才給出結論。
用一個簡化的類比來理解:這就像考試時,老師要求你「寫出計算過程」,而不是只交一個最終答案。這樣做的好處有兩個:

1. 推理過程本身,會迫使 AI 更仔細地檢視資料,而不是跳過細節直接猜結論
2. 你可以檢查推理過程,判斷結論是不是真的站得住腳——如果推理過程本身就有問題(例如引用了不存在的數字),你能立刻發現,而不是只看到一個「看起來合理」卻可能有問題的結論
   三、怎麼在 prompt 裡引導 Chain-of-Thought
   最簡單的做法,是在需要判斷的任務指令裡,明確要求先列出推理依據,再下結論。例如:

請針對本週事件處理效率進行評估,並依照以下步驟進行:

1. 先列出本週的關鍵數據(事件總數、已結案數、平均處理時間)
2. 將這些數據與資料中提供的上週數據做對比
3. 根據以上比較,說明效率是提升、持平還是下降,並具體指出判斷依據
4. 最後,用一句話總結結論

請完整寫出第 1-3 步的過程,不要只給第 4 步的結論。
這種寫法,把「直接要答案」拆解成「先攤開證據、再逐步推導」的流程,大幅降低 AI 跳過思考直接臆測的機率。
四、Chain-of-Thought 跟前面學過的技巧怎麼搭配
CoT 不是獨立存在的技巧,它跟前面幾天的內容緊密相關:

• 跟 Day 11 防呆機制搭配:如果 CoT 過程中,AI 發現「資料不足以做出第 2 步的比較」(例如根本沒有提供上週數據),防呆規則會要求它誠實標註,而不是硬湊一個比較結果——這正是兩個技巧疊加後,效果比單獨使用更好的地方
• 跟 Day 8 結構化輸出搭配:你可以把「推理過程」設計成報告裡的一個獨立章節(例如「分析依據」),讓這個過程不只是內部運算,也直接呈現在最終報告裡,增加報告的可信度與可查核性
  五、什麼時候該用 Chain-of-Thought,什麼時候不需要
  CoT 不是每個任務都需要。一個簡單的判斷原則:
• 單純的資料整理與排版(例如把事件清單條列出來)→ 不太需要 CoT,因為這不涉及推論判斷
• 需要比較、歸納、或下結論的任務(例如判斷趨勢、評估整體風險等級)→ 適合使用 CoT,讓判斷過程透明化
  過度使用 CoT,會讓每個任務都變得冗長、拖慢處理速度,也會佔用更多 Day 14 談過的 Token 額度。只在真正需要「判斷」而非「整理」的環節,才動用這個技巧。
  六、今天的行動練習
  回頭檢視你目前範本裡,哪些部分其實隱含著「需要 AI 做判斷」的任務(而不只是單純整理資料)?挑出一個,試著用今天的句型,把它改寫成「先列步驟、再下結論」的 CoT 格式,並比較改寫前後,AI 給出的內容有沒有更站得住腳。

小結
今天的核心觀念是:遇到需要判斷的任務,不要讓 AI 直接跳到結論,而是要求它把推理過程攤開來寫。這不只讓判斷更可靠,也讓你有機會檢查它的邏輯是否合理——這跟 Day 11、12 談的防呆機制,是同一套「不要盲目相信、要求透明化」精神的延伸應用。
下一篇,我們要把 Chain-of-Thought 實際套用在一個具體任務上——教 AI 幫你判斷「本週事件趨勢與嚴重性」,同時處理這個任務裡最容易踩雷的地方。